leftwikiaorg-20200213-history
King County Democrats/Communications
Introduction The Communications Committee of the King County Democrats is responsible for coordinating our communications strategy with our members and activists within King County. There are two sub-committees: PCO Coordination Committee *Works with the Training Committee to develop training materials and events to help our PCO's build their networks within their neighborhood. Online Infrastructure Committee *Works with webmasters for the Legislative Districts within King County to review and improve our use of websites, mailing lists and social networking. If you are interested in one (or more) of the sub-committees, please let Chad know. Thanks very much for all you do for Democratic politics. Proposed Resolution Whereas, advances and adoption of technology over the past decade allow us to communicate extremely rapidly with our members, potential members, elected officials, and the media. Whereas, it is important for the King County Democrats organization to be able to rapidly respond to political and legislative developments Whereas, it is also imperative that statements (or actions that could be perceived to be statements) of the organization be approved by the chair and reviewed by as broad a group as feasible in the time necessary. Therefore, be it resolved that the Executive Board of the King County Democrats approves the below Communications policy: :The organization shall maintain the below mechanisms of communication: *A monthly newsletter in print and online *Press releases *A KC Dems blog *A community calendar *A membership database *LAC Blog (and other committee blogs as appropriate) *"Admins" shall be defined as the following KC Dems elected and appointed officers: Chair, Vice-Chair for Communications, LAC Chair(s) *"LD Power Users" shall be LD Chairs and their designates. Print Newsletter Anyone may submit an article for consideration for the print newsletter. The KC Dems Chair shall serve as the print newsletter editor. Meeting agendas must be published in the print newsletter. Proposed resolutions should be published in the print newsletter (if time allows) Previous meeting minutes (including resolutions or endorsements) should be published in the print newsletter Press Releases Press releases should only be done after an official action of the KCDCC All Press Releases must be approved by the Chair Press releases should be cross-posted on the KC Dems blog The KC Dems Chair and Vice-Chair for Communications shall be authorized to speak to the (mainstream) media on behalf of the organization. All (mainstream) media queries should be directed to the Chair (and optionally also to the Vice-Chair for Communications) Blog :http://www.kcdems.org Anyone may submit a blog entry for consideration "Admins" shall have the ability to post directly to the KC Dems blog Meeting agendas, meeting minutes, and press releases should be posted to the KC Dems blog Unless it is: Meeting Agenda, Meeting Minutes, or a Press Release, all posts must be signed by the admin who posted them All posts must be consistent with the KC Dems Platform (http://www.kcdems.net/about/2006platform.aspx) and/or consistent with a resolution Community Calendar :http://www.kcdems.org/calendar/ Anyone may submit an event for consideration for the community calendar LD Power Users can approve an event for their LD which will include listing on the Community Calendar Admins should be able to approve any event for listing on the Community Calendar Activist Database :http://www.kcdems.net/manage/activists.aspx Anyone may add an activist to the database (http://www.kcdems.net/volunteer.aspx) LD Power Users should be able to view and edit activists for their LD Admins should be able to view and edit all activists in the database Only the individual activist should be able to delete themselves from the database eNewsletter KC Dems should send a ~bi-weekly eNewsletter to members of the Activist Database Anyone may submit content for the eNewsletter The Vice-Chair for Communications shall be the editor of the eNewsletter Content from the eNewsletter must be approved by the KC Dems Chair Other Communications Any other communications sent on behalf of KC Dems (like an action alert or petition) must be approved by the KC Dems Chair A "leadership" email list consisting of elected officers, appointed officers, and LD Chairs shall be setup for open discussion among this group A "eboard" email list consisting of the above plus LD KCDCC Committeepeople, Vice-Chairs, and KCDCC Alternates shall be setup for sharing announcements among this group LAC Blog :or other Committee Blogs The KC Dems LAC shall maintain its own blog. The Chair of the committee shall be responsible for the content; which should be consistent with the above policies. Brainstorming Chad Lupkes writes: LAMP. Linux, Apache, MySQL, Php, with some javascript and Ajax thrown in for good measure. Roger Crew writes: hm, which Linux distribution? Actually the question I should have asked is whether (1) this is a dedicated box where you can install whatever you want modulo available disk space, (e.g., perl, mod_perl, ImageMagick, custom CGI binaries to do various optimized searches) or whether (2) this is a hosting-provider package where you get the specific applications they list, you pay extra for anything else, and they're completely paranoid about letting people compile/install their own executables > But we need a plan, and we need to collaborate on the Systems Development Life Cycle. Planning, Analysis, Design, Development, Testing, Implementation, Maintenance Probably the first order of business is to nail down the various services one might care about providing and in what priority. Just as a first cut/thinking-out-loud it might be helpful to subdivide things a number of ways: * Kinds of services ** Data (raw or processed to varying degrees) ** Maps and Map components * Data granularity needed ** (Precinct level) things that rely only on precinct/LD/CD/CC info that we've actually been collecting multicounty and therefore currently have SOME hope of doing statewide ** (Dstcode level) things that rely on dstcode-like info that we currently have for King County that we MIGHT be able to collect from other counties but haven't really yet. This mainly has to do with school districts and such where the boundaries don't align with precinct bounds ** (Parcel level) things that require serious analysis of the parcel layer, that may actually be POSSIBLE to do in King County given what we have now, but are probably hopeless statewide until such time as disk space gets really, really cheap (and it might). and, orthogonal to all of this (x) Geocoding things that involve resolving a street address to a particular location, which subdivides into (*) things we can do if somebody provides this (*) how to provides this ourselves which I separate out because other people do provide geocoding. However, the accuracy tends to be a mixed bag, and it tends to cost $$ if you're, say, an LD admin or a campaign who wants to do a few hundred or a few thousand in a single batch. (3) Customers (a) PCOs (i.e., people who only care about a single precinct) (b) Admins (for LDs, counties, campaigns, and other folks doing wide-area views of things) (4) Access/Authentication/Authorization issues needs to be talked about but I suddenly found myself writing a whole 'nother batch of text so I'm going to defer it to another message. Data This would essentially be a webservice, i.e., queries submitted would receive responses in some JSONish/XMLish format which would then be usable on the client side to generate maps, paste lines/regions into Google, or incorporate into a variety of other applications (see below). Note that the vast majority of this is really topological or jurisdictional data rather than strictly graphical data. Precinct level * (*p) precinct -> all jurisdictions * (*pc) precinct -> list of adjacent precincts * (Gp) precinct -> boundary * (*) jurisdiction -> list of precincts * (Gc) precinct list -> exterior boundary * (G) precinct -> annotation point Dstcode level * (*p) precinct -> list of dstcodes * (*p) dstcode -> precinct * (*p) dstcode -> all localjurisdictions * (Gpc) dstcode list -> exterior boundary * (Gp) dstcode -> annotation point * (*) localjurisdiction -> list of dstcodes Parcel Layer * (*) canonical address -> parcel * (*) parcel -> lat+long of annotation point * (*) parcel -> street segment * (*) street segment -> list of parcels on each side * (*) precinct/dstcode -> list of parcels * (*) precinct/dstcode -> list of street segments * (G) street segment -> arc * (G) parcel -> boundary * p = of interest to PCOs * G = actual graphical data * I = queries that need non-trivial/optimized/graphical indices * * = regular db table stuff terminology "jurisdiction" County, LD, CD, City, County Council/Commission (CC) district, or other kind of district known to align with precinct boundaries "localjurisdiction" school, fire, water, or other kind of district that mostly does NOT align with precinct boundaries "dstcode" portion of a precinct that is within a single set of localjurisdictions (i.e., same school, same fire, same water, etc...) "annotation point" centroid or other point within the boundaries of the given area that's far enough inside to be a legible place to put annotations on that area when drawing a map. "canonical address" street address in the county's canonical form (e.g., Predirectional + House# + Stname + Sttype + Postdirectional for King County) "exterior boundary": drawing a group of precincts but with the internal boundaries between members of the group suppressed. Also note that being able to do exterior boundaries and precinct adjacency lists requires having a COVERAGE (half-edge data structure linking vertices and areas), which is more than what a polygon shapefile by itself gives you, but can be derived easily enough if the shapefile is clean -- but it still needs to be done, and once done there's some argument for preferring keeping things stored that way in the DB rather than as independent polygons (i.e., what the shapefile format gives you by itself). Geocoding basically we're talking about the following kinds of queries (I) lat+long -> precinct (Ip) lat+long -> dstcode (I) canonical address -> lat+long It turns out that with King County's ST_ADDRESS layer one can do an approximate geocode that's *mostly* good enough to do canonical address -> precinct canonical address -> dstcode I've actually implemented this much, the problem being that it's silently WRONG some percentage of the time and you never find out. However, with the PARCEL layer and the assessors db extract, and a sufficiently large chunk of memory/disk to play with, one can then resolve addresses to parcels directly, at which point you have an exact geocode (or the negative info that the address doesn't correspond to a known building; or it's an apartment complex where some building within has a distinct address from whoever has the main property account and therefore it's not listed in Assessor Land; bleah...) Map Drawing we do *not* want to replicate what Google already does. And if we get too elaborate on map drawing, the load/bandwidth from this will swamp everything else. However there *will* be some call for things that can work independently of Google. One idea is to have some number of pre-canned views at various sizes/resolutions, and then be able to (*) generate SVG for that view which can then be rendered in SVG-aware browsers (like Firefox 1.5+ or IE with the adobe plugin) (*) given a POST request with a coloring/annotation scheme, produce a .gif with precincts colored/annotated thus and a element for use with that .gif so that it's mousable. Applications You probably have your own favorites, but here are various things I'm thinking about in order from trivial to less so. (A) looks mostly trivial once we have the queries set up, (B) I've already done for the 41st, and one of the points of this exercise is to make it doable for everybody else © is currently approaching the proof-of-concept stage (D) and (E) are complete vaporware and I'm not making any promises yet but it seems like something should be possible (F) is trivial once you have (D) and (E) and once the VoteBuilder folks can be convinced to allow cross-platform scripting to retrieve query results (which is a big if, I'll admit...) but by this point we've conquered the world anyway, so... (A) graphical report generator (given some data values for a particular LD/area, specify thresholds for doing a histogram and then generate a colorful map) (B) the precinct(/whatever) selector widget (something to replace the pick-a-precinct box see © Precinct Caucus "Gerrymander" Tool (PC organizer has to break up her LD into groups of precincts. This displays a table with data columns pulled in from various sources showing various stats for each of the areas she's defined thus far (e.g,. # of PCOs, # of delegates allocated, # registered voters, # Kerry voters, list of convener volunteers, list of known personality conflicts, whatever...) which then updates as she shuffles precincts between areas. (D) Precinct Map From Hell parcels labeled by house number, with slightly different shadings or extrathick bounds around parcels associated with each distinct street name, labeled street arcs, significant elevation changes along street arcs (i.e., hills) marked appropriately. (E) Walklist Analysis tool given a list of street addresses in canonical form identify the parcels, then split the list into street segments with houses ordered in some feasible walking order within each segment, (F) single page with ajax calling out to votebuilder to get (XML/JSON) list of addresses from whatever query the user has just run, and then doing Walklist Analysis, followed by display of (1) reordered walklist segments in some printable form (2) Precinct Map From Hell with parcels highlighted